Delphi Language Changes

The Delphi for Microsoftâ .NET Preview compiler is more than a port to a new platform. The new version of the compiler requires

 

• A new code generator
• A new linker
• New runtime library
• New language syntax (e.g. to support custom attributes)

 

In order to fully embrace the CLR, and make Delphi a first class citizen in the new world of managed code, some language features must be deprecated, and others are the subject of ongoing research. Though many of these details are still being researched and implemented, it is hoped that the following sections will help you begin to migrate your existing unmanaged Win32 Delphi applications to the .NET Framework.

Unsafe code Warnings in Delphi

Starting with Delphi 7, the compiler includes three new warnings that can help you locate code that is non-portable (i.e. it uses a deprecated language feature or type), or unsafe in the .NET Framework. In the .NET Framework, unsafe simply means that the code cannot be verified by the static analysis performed by the CLR, when the code is loaded. The compiler can warn about the usage of unsafe types, unsafe code, and unsafe casts.

 

Unsafe types

• PChar
• Untyped pointers
• Untyped var and out parameters
• File of <type>
• Real48
• Variant records (records containing overlapping fields)

 

Unsafe code

• Absolute variables
• Addr(), Ptr(), Hi(), Lo(), Swap() standard procedures
• BlockRead(), and BlockWrite()
• Fail()
• GetMem(), FreeMem(), ReallocMem()

 

Unsafe casts

• Casting an object instance to a type that is not an ancestor or descendent of the instance type
• Casting a record type to anything else

 

These new warnings are disabled by default. They can be enabled with the IDE Project Options dialog box, or with the compiler directive:

 

            {$WARN UNSAFE_CODE ON}

 

They can also be enabled with the -W command line switch:

 

            dcc32 -W+UNSAFE_CODE

 

Note there is no space before or after the '+' character on the command line switch.

These new warnings are in the Delphi 7 (and beyond) compiler (dcc32). They are not in the Delphi for .NET Preview compiler (dccil).

Extended identifiers

You might encounter CLR identifiers (e.g. types, or methods in a class) having the same name as a Delphi language keyword. For example, a class might have a method called begin. Another example is the CLR class called Type, in the System namespace. Type is a Delphi language keyword, and cannot be used for an identifier name.

 

If you qualify the identifier with its full namespace specification, then there is no problem. For example, to use the Type class, you must use its fully qualified name:

 

      var
         TMyType : System.Type; // Must use fully qualified namespace.

As a shorter alternative, Delphi for .NET introduces the ampersand (&) operator to resolve ambiguities between CLR identifiers and Delphi language keywords. If you encounter a method or type that is the same name as a Delphi keyword, you can omit the namespace specification if you prefix the identifier name with an ampersand. For example, the following code uses the ampersand to disambiguate the CLR Type class from the Delphi keyword type:

 

      var
         TMyType : &Type; // Prefix with '&' is ok.

Deprecated Language Features

This table contains Delphi language features that are being deprecated, and are not supported in this Delphi for .NET Preview release.

 

Keyword/Language Feature	Notes
Real48 six byte floating point type
GetMem(), FreeMem(), and ReallocMem()	Use dynamic arrays, or rely on automatic dispose pattern implementation
BlockRead(), BlockWrite()
Absolute directive, Addr, and @
Pre-Delphi object syntax (type foo = object)
TVarData, Variant internals	Variant semantics will be supported but not as TVarData.
File of <type>	This construct cannot be implemented because the Delphi compiler cannot know the size of <type> on the target platform (e.g. a handheld device). The JIT compiler for the specific platform determines the size of intrinsic types.
Untyped var and out parameters	Untyped const parameters are still supported.
PChar	In a future release Delphi for .NET will support unsafe managed code (i.e. pointers). Unsafe, unmanaged pointers are not supported in the preview release.
automated and dispid directives
Inline assembly - asm statement
TInterfacedObject	AddRef, QueryInterface, and Release are deprecated. In the preview release TInterfacedObject is an alias for TObject.
Dynamic interface aggregation	Dynamic aggregation of interfaces is not supported by the CLR, because it cannot be statically verified. In Delphi for .NET, all interfaces must be declared on the type.
ExitProc

 

Implementation Changes

Random Number Generation

The Delphi for .NET Preview compiler uses the CLR class System.Random to generate psuedo-random numbers. You should take note of this change, if you have been relying on the previous implementation to generate a certain sequence of numbers.

 

You can still seed the algorithm with a LongWord value. If you want to use the default seed value of zero, call the Randomize function. You can then generate psuedo-random numbers by calling the Random function. If you want to use your own seed value, set the value of the global variable RandSeed, and then call Random. You can reseed the algorithm by setting the RandSeed variable to a new value.

The DateTime Type

The .NET Framework class library implements a value type called DateTime, in the System namespace. The implementation of this type differs from that of Delphi, which uses the OLE Automation implementation.

 

The .NET Framework DateTime class contains the methods FromOADate and ToOADate. These methods are used to convert from an OLE Automation DateTime to a System.DateTime.

Research Items

The following Delphi language features are currently undergoing research and are changing rapidly. Some of these items are required to fully support the CLR, and others are existing Delphi language features that have no CLR equivalent. These items are not fully supported in the Delphi for .NET Preview release, and are subject to change in future releases of the product.

 

• Sealed classes. A new Delphi language keyword, sealed, is introduced. The sealed attribute is applied to classes. A sealed class cannot be extended by any CLR consumer (neither Delphi, nor any other language).
• Final methods. A new Delphi language keyword, final, is introduced. The final attribute is applied to class methods. A method with the final attribute cannot be overridden in a derived class.
• Virtual (polymorphic) constructors. The CLR has no notion of polymorphic constructors. This will be a difficult issue for descendents of TComponent, where the descendent is expected to have a virtual constructor.
• UTF-8 encoded Unicode characters in source code
• Nested types (i.e. declaring a new type within the scope of an enclosing type declaration)
• Non-virtual methods in records
• Class (static) data
• Class properties
• Class (static) methods
• Virtual methods in class helpers
• Multicast events. The assignment operator will have singleton semantics for traditional Delphi assignment of events. The current plan is to allow the ':=' operator to replace the last event assigned, without effecting events assigned by external managed consumers. Assigning the value of nil will remove the last event assigned.
• Variant internals. Variant semantics will be supported as TObject, not as TVarData.
• Automatic boxing of value types into CLR objects

The Experimental Directive

A new "hint" directive has been introduced to the Delphi compiler: experimental. The experimental directive works the same way as the other hint directives, deprecated, platform, and library. When code is compiled in the {$HINTS ON} {$WARNINGS ON} state, the experimental directive generates a hint.